…e output

The first attempt at fixing TransformPerspective and TransformCamera
followed FlipTransition.paint()'s viewport-mapping pattern verbatim.
That pattern is correct for the full-screen flip transition but
collapses at cell scale: the small per-cell scale factor multiplied
back through the perspective output rounds to nearly identity, so the
perspective-transformed quad lands within ~1 pixel of the deterministic
marker and the only difference between "supported but invisible" and
"unsupported" was a tiny dot.

Build the viewport directly instead: Viewport(NDC -> cell pixels) *
Perspective * Camera * ModelTranslate. The viewport is a translate-
then-scale matrix that maps NDC (-1..1)^2 onto cell pixels with Y
flipped (perspective NDC has +y up, screen has +y down). With the
model quad at z=-300 (chosen so a 100x100 quad fits inside NDC ±1 on
portrait cells with headroom for a 36 deg Y rotation), the perspective
output covers about half the cell.

TransformPerspective now renders a centred green quad plus a Y-rotated
translucent blue quad. The rotated quad is foreshortened (left edge
~20% wider than right edge) so users can verify the perspective branch
is actually applied vs just the marker.

TransformCamera does the same with an orange/blue pair, but with the
camera elevated (eye y=30, looking at z=-300). The ~5.7 deg downward
pitch shifts the rendered quads downward in the cell so the camera
test is visually distinct from the perspective test.

Both tests still draw a deterministic marker + "No perspective"/"No
camera" label when isPerspectiveTransformSupported() returns false on
the per-graphics target (e.g., iOS Metal mutable images).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous attempt built a Viewport*Perspective*Camera*ModelTranslate
matrix and applied it via g.setTransform(mvp) followed by fillRect.
That depends on the platform's draw path applying the 4x4 perspective
matrix to rect rasterization, which fails in two places:

- Android Canvas converts the 4x4 to a 3x3 Skia matrix (drops the Z
  axis). canvas.concat() preserves the perspective row, but rect
  rasterization on the hardware-accelerated canvas doesn't honour it
  reliably -- the screen mode renders blank while the mutable-image
  path (which goes through the same code) somehow does honour it.

- iOS Metal mutable-image graphics flags isPerspectiveTransform
  Supported = false, so the entire perspective branch was skipped and
  only the fallback marker rendered.

Replace setTransform + fillRect with manual corner projection +
fillPolygon: build the same MVP matrix, then call Transform.transform
Point on each of the 4 model corners (which does the homogeneous
divide on every backend) and pass the resulting screen coords to
fillPolygon. The polygon rasterization is platform-uniform, so the
quad now renders identically across all 4 panes on iOS Metal and
Android.

Switch the gate from g.isPerspectiveTransformSupported() (per-graphics)
to Transform.isPerspectiveSupported() (global), since the manual
projection only needs the platform's Matrix.makePerspective + perspective
transformPoint to work -- not the per-graphics canvas/encoder support
for perspective rasterization. JavaSE still returns false and falls
back to the deterministic marker.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The NativeGraphics.setTransform helper at IOSImplementation.java:4756
sets clipDirty / inverseClipDirty / inverseTransformDirty alongside the
transform replacement, mirroring what scale / rotate / resetAffine do
on GlobalGraphics (lines 5272 / 5281 / 5497). The Override-level
impl.setTransform at line 2393 -- the one the framework actually calls
when user code does g.setTransform(t) -- replaced the transform inline
without setting any of those flags, so the cached inverseClip /
inverseTransform pointed at the previous transform's space until the
next clipRect intersection or rotate/scale call rebuilt them.

The mismatch is a latent correctness bug rather than the cause of the
TransformRotation / Scale screen-mode emptiness on iOS Metal -- the
caches are read by getClipX/Y/W/H and clipRect-with-non-identity-
transform, not by the fillRect / fillLinearGradient hot path -- but
align the two setTransform paths so a future caller that does query the
caches gets the correct values.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The screenshot pipeline silently shipped TabsTheme_light's image bytes
under MultiButtonTheme_light's filename on iOS Metal in PR #4875 --
both decoded streams reassembled to the same MD5, but the comparator
had no way to tell that the bytes attributed to MultiButtonTheme_light
were actually a previous test's pixels. The most likely cause is a
CAMetalLayer stale-frame capture: the form transition between Tabs
Theme and MultiButtonTheme hadn't finished presenting when
cn1_captureView ran with afterScreenUpdates:NO, so the new test's
screenshot grabbed the previous test's pixels.

Add a detection signal at the emit boundary:

- Cn1ssDeviceRunnerHelper computes a 64-bit FNV-1a hash of every
  emitted PNG and logs `png_fnv1a64=<hex>` on the existing CN1SS:INFO
  line.
- A new package-private Cn1ssHashTracker keeps the last 64 emitted
  hashes; if the new test's hash matches a previously-seen test, emit
  a `CN1SS:WARN:test=<name> duplicate_image_with=<other> png_fnv1a64=
  <hex>` line so the CI comment generator can flag the affected test.
- Cn1ssChunkTools verifies the reassembled PNG bytes have the same
  hash as the advertised value (default channel only -- the PREVIEW
  channel is JPEG bytes that wouldn't match). Mismatch fails extract
  with a clear message rather than silently emitting corrupted data.

The hash is FNV-1a rather than SHA-256 / CRC32 to avoid pulling
java.security or java.util.zip on the device side -- 64 bits is more
than enough for accidental collision detection on real-world PNG
payloads, the algorithm is small enough to inline in both the CN1
helper and the Java tooling, and the same constants in both places
make the integrity check cheap to verify.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous Cn1ssHashTracker used `private static final Map<String,
String> hashToTest = new LinkedHashMap<>()` to track recently-emitted
screenshot hashes. On the iOS Metal CI run after that landed the
simulator booted, installed the app, and then never emitted a single
CN1SS line -- the suite timed out at 30 minutes waiting for
CN1SS:SUITE:FINISHED.

Cn1ssDeviceRunner.java:215-222 documents this exact failure mode:

  static collections initialised via a static method call (or a
  method-call initializer for DEFAULT_TEST_CLASSES) both broke iOS
  class loading -- Cn1ssDeviceRunner failed to load before runSuite()
  could even log a single starting test=... entry, leaving the suite
  to time out at the 300s end-marker deadline. Keep all skip lookups
  inline to avoid triggering the same static-init failure path.

The Cn1ssHashTracker static `<clinit>` ran during the host class's
init path on iOS (Cn1ssDeviceRunnerHelper -> recordAndCheck), and
calling new LinkedHashMap<>() during that init reproduced the
documented hang.

Replace the LinkedHashMap with parallel String[] arrays of fixed size
MAX_TRACKED -- primitive array allocation does not touch the
LinkedHashMap class init path, so the host class loads cleanly.
Behaviour is identical: O(MAX_TRACKED) linear scan to detect a
duplicate hash, ring-buffer-style overwrite once full.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The fix-graphics-screenshot-tests rewrites of Scale, AffineScale,
TransformPerspective and TransformCamera produce different bytes than
the previous golden set (which were captured against the broken pre-
fix tests). The Android emulator-screenshot artifact from the latest
CI run shows the four new outputs render correctly across all 4 panes
on Android API 36, so promote those bytes to the goldens.

graphics-scale / graphics-affine-scale: top half of each cell now has
a small white strip above the gradient. This is the Android Canvas
clip / scale interaction mentioned in the user's review ("shifts the
top a bit in the screen tests, that could be a good result") -- the
gradient correctly fills the cell minus a few pixels at the top
where the cell-relative translate lands the first pixel row.

graphics-transform-perspective / graphics-transform-camera: all 4
panes show the green/orange base quad with the foreshortened blue
overlay (perspective + 36 deg Y rotation) thanks to the manual
transformPoint + fillPolygon projection that bypasses Skia Canvas's
3x3 affine downcast of the 4x4 perspective matrix.

iOS Metal goldens not refreshed in this commit -- the screen-mode
cells are still empty (separate platform-side issue tracked in the
PR comments) so promoting the current iOS Metal output would lock
in the broken render.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The hash verification I added in c3011a7 used a `\b` word boundary
to terminate the test-name match in the CN1SS:INFO regex:

  "CN1SS:INFO:test=" + Pattern.quote(testName) + "\\b[^\\n]*?\\bpng_fnv1a64=..."

`\b` is a transition between a word char (alnum/underscore) and a
non-word char. Both `_` and `-` are non-word chars, so for testName=
graphics-draw-string the `\b` is satisfied by the boundary between
`g` (word) and `-` (non-word) on both:

  CN1SS:INFO:test=graphics-draw-string ...
  CN1SS:INFO:test=graphics-draw-string-decorated ...

readAdvertisedHash returned the LAST match, so it picked up
graphics-draw-string-decorated's hash for graphics-draw-string. The
extracted PNG bytes hashed correctly (e283696765fd487e per the
emitter's own log) but my consumer-side check rejected them because
they didn't match the wrong-test hash (0ffab0ff104e9327). Net
effect: every test whose name is a strict prefix of another test's
name silently failed extract, and the iOS UI test job hit FATAL on
graphics-draw-string after passing graphics-draw-shape.

Replace `\b` with `(?![A-Za-z0-9_.\-])` -- the same character class
the chunk pattern uses for test names. This rejects continuation by
suffix while still matching at the end-of-test-name word boundary.

Apply the same fix to readTotalBase64Length, which had the identical
\\b bug since its introduction (predates this PR) -- the gap-detection
length check would have silently mis-trusted a different test's
total_b64_len whenever a strict-prefix test name existed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

When the primary device-runner.log loses chunks for a large test (the
iOS unified-log syslog stream occasionally drops lines under load) the
script falls back to log show --predicate, decodes the PNG from there,
and logs "Decoded screenshot for 'X' from fallback". The fallback path
was missing two things compared to the primary path:

1. It didn't append to TEST_OUTPUT_ENTRIES, so the comparator never saw
   those tests. iOS Metal compared 84 screenshots vs the 90 it had
   streams for; the missing 5 were exactly the large transition tests
   (CoverHorizontalTransitionTest, SlideHorizontalTransitionTest,
   SlideHorizontalBackTransitionTest, SlideVerticalTransitionTest,
   SlideFadeTitleTransitionTest) whose ~288-chunk streams hit logcat-
   style line drops in device-runner.log but survived in the syslog
   fallback.
2. It didn't decode the PREVIEW channel from the fallback log, so the
   PR comment for those tests had no inline thumbnail when the fallback
   was needed.

Mirror both steps from the primary path in the fallback branch.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…/camera

The transformPoint+fillPolygon rewrite from a6570dd produces visible
foreshortened quads on all 4 panes on iOS Metal, matching the Android
output. Promote the latest CI artifact bytes to the iOS Metal goldens
so subsequent runs match cleanly.

graphics-affine-scale / graphics-scale goldens are NOT updated -- the
top half of the cell (form Graphics path) is still empty on iOS Metal
because g.setTransform(t) for non-translation transforms isn't applied
to fillRect / fillLinearGradient on the screen encoder, while the
bottom half (mutable image path) renders correctly. That's a platform
bug in the iOS Metal port, separate from this PR's test-fix scope.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

setTransform's default branch (TYPE_UNKNOWN composed transform) copies
the native matrix data via impl.copyTransform but doesn't mark the
Transform's cached state as dirty. The TRANSLATION / SCALE / IDENTITY
branches all set `dirty = true` so getNativeTransform() will re-run
initNativeTransform on next access. Match that contract in the default
branch -- for TYPE_UNKNOWN initNativeTransform's switch hits default
break and doesn't actually resync the matrix data, but the dirty flag
is the externally-observable signal that the native cache is fresh.

This is the lowest-risk fix attempt for the iOS Metal port bug where
g.setTransform(t) with composed transforms (TYPE_UNKNOWN) silently
fails to apply on the form-Graphics screen encoder while
g.rotate / g.scale / g.translate (which go through ng.rotate etc.)
work correctly. Both paths construct identical 4x4 matrix data in
the end and call nativeSetTransform with the same 16 floats, so the
exact failure mechanism is still mysterious -- but the dirty-flag
contract diverges between the working and failing paths and matching
it is a sane defensive change. See memory note
project_metal_settransform_screen_unrendered for the open
investigation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

On platforms where impl.isTranslationSupported()=false (iOS), the
Graphics class accumulates xTranslate/yTranslate locally and bakes them
into vertex coordinates passed to impl fill primitives. The user's
setTransform matrix was then applied by the GPU on top of those
already-translated vertices, which double-counts the cell origin for
any non-translation matrix (rotate, scale, shear) and threw the gradient
off-screen. graphics-affine-scale, graphics-scale, and
graphics-transform-rotation rendered blank top (screen) cells while the
bottom (mutable, where xTranslate=0) cells worked correctly.

Conjugate the user's matrix with T(xTranslate, yTranslate):
T(xT, yT) * userMatrix * T(-xT, -yT) so its effect is independent of
any prior g.translate() (matches the canvas-matrix semantics on
Android/JavaSE). getTransform() returns the original user matrix from a
new userTransform field; g.translate() re-conjugates if a non-identity
userTransform is active; resetAffine() clears it. Pure-translation
matrices conjugate to themselves so TransformTranslation behavior is
unchanged. Triggers only when xTranslate||yTranslate != 0, so
Android/JavaSE (isTranslationSupported=true) are untouched.

Confirmed locally with diagnostic logging (now removed): the AffineScale
top cells which were blank now render the red->blue gradient like the
mutable cells. Replaces the speculative dirty-flag tweak in commit
292b980 with the actual root cause / fix; clean up the now-stale
comment in IOSImplementation.setTransform that referred to the
empty-top-cells symptom.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Concurrent build-ios + build-ios-metal CI jobs both push to the
cn1ss-previews branch in parallel. The second job's push got rejected
("rejected, fetch first") which threw IOException, the comment-post
step aborted, and the PR was left with a stale screenshot comment from
an earlier run -- transform-camera/perspective looked like they were
still differing even though the goldens had been promoted, because the
post-promotion comment never made it onto the PR.

Retry up to 5 times with fetch + rebase. If rebase conflicts (the other
job overwrote the same pr-N/subdir tree) reset to FETCH_HEAD, re-apply
our own preview files on top, and try again with a clean single commit.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous commit unconditionally conjugated the user matrix with
T(xTranslate, yTranslate) in Graphics.setTransform whenever
xTranslate/yTranslate were non-zero. That assumed every platform with
isTranslationSupported()=false had the same iOS-style render path
(vertex coords carry xTranslate, GPU applies the user matrix on top).
Android also returns isTranslationSupported()=false but its render
path concats the user matrix into the canvas at draw time -- the
existing semantics there were "shifted but visible" rather than
"vanishes off-screen", and the conjugation moved elements out of view
when CN1 framework code (LinearGradientPaint, FlipTransition,
CSSBorder, ChartComponent, scene Node) called setTransform with a
non-translation matrix during normal rendering.

Add CodenameOneImplementation.isSetTransformTranslationConjugationRequired()
(default false) and override to true only on iOS where the bug actually
manifests. Graphics.setTransform / translate now check this flag
before conjugating, so Android and any other isTranslationSupported=
false port keep their previous setTransform pixels.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

This reverts commit a54efa0.

…yTranslate"

This reverts commit 67ec8ff.

Avoid relying on g.setTransform(translate * scale) on the form-Graphics
path -- that pattern hits the iOS xTranslate-double-count bug and the
fix in Graphics.setTransform breaks the picker / scene Node renderers
which intentionally bake xTranslate into their own transforms. Render
the red->blue gradient at native 200x100 into a mutable Image (where
xTranslate=0 so fillLinearGradient works directly) and drawImage it
stretched into each half of the cell. Mirror the bottom half by
flipping the RGB buffer column-wise so the right-to-left variant the
old test demonstrated is preserved without ever calling setTransform on
the form Graphics.

Same approach as TransformPerspective / TransformCamera (manual local
rendering, then composite at draw time).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ble Image"

This reverts commit 6b7e20a.

…roid/JavaSE

On every port where impl.isTranslationSupported()=false (iOS, Android,
JavaSE) the Graphics class accumulates xTranslate/yTranslate locally
and bakes them into the vertex coordinates passed to fill primitives.
The platform render path then applies the user's setTransform matrix
on top of those already-translated vertices -- iOS Metal does it via
the GPU vertex shader (`projection * modelView * userTransform * pos`),
Android via `canvas.concat(t); drawRect(x+xT, y+yT)`, JavaSE via
Graphics2D matrix replacement followed by drawRect at the
xTranslate-shifted coords. The result for any non-translation user
matrix double-counts the cell origin, so the same CN1 code emits
slightly-shifted output on Android and JavaSE and catastrophically
off-screen output on iOS Metal at native pixel resolution.

Rather than putting the workaround in user code (the previous attempt
went via mutable-Image+drawImage), conjugate uniformly:
  T(xTranslate, yTranslate) * userMatrix * T(-xTranslate, -yTranslate)
in Graphics.setTransform. The user-visible setTransform is now
translate-independent on every port. getTransform() returns the
original matrix from a new userTransform field; g.translate()
re-conjugates if a non-identity userTransform is active; resetAffine()
clears it. Pure-translation conjugates to itself so TransformTranslation
is unchanged. Gated behind impl.isSetTransformTranslationConjugationRequired()
(default false) and overridden true in iOS / Android / JavaSE.

Two existing CN1 framework callers had been compensating for the
double-count with their own inline T(absX) * X * T(-absX) conjugation
around scene.absX / component.absX. That stops being necessary now
that Graphics.setTransform handles the translation uniformly, and
leaving them in would double the conjugation and break the picker /
ChartComponent on every isTranslationSupported=false port. Drop the
manual conjugation from:

  - com.codename1.ui.scene.Node.render
  - com.codename1.ui.scene.Node.getLocalToScreenTransform
  - com.codename1.charts.ChartComponent.paint

CSSBorder's `g.setTransform(rotate(angle, contentX, contentY))` already
uses component-relative contentRect coordinates, so the platform-side
conjugation correctly lands the rotation centre at
xTranslate + contentX = component.absX + contentX = content centre in
screen coords. FlipTransition.paint runs with xTranslate=0 (transitions
paint at form level, not nested), so the conjugation is a no-op there.
LinearGradientPaint.paint already does `g.translate(-tx, -ty)` before
its setTransform call, so xTranslate is 0 at the call site and the
conjugation is also a no-op.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The polyline-collapse fix in d9952d4 didn't unblock the iOS XY
chart blank -- chart-line/bar/etc all still hash identical to the
all-blank PNG. Multi-subpath isn't the trigger then. Next suspect:
the chart compat Paint defaults strokeJoin to BEVEL, while the
graphics-draw-shape test (which renders correctly on iOS GL+Metal)
uses Stroke.JOIN_MITER for the triangle and JOIN_ROUND for the curve
-- neither uses BEVEL. The iOS native Stroker.c has explicit
drawJoin branches for JOIN_MITER and JOIN_ROUND but falls through
to a plain emitLineTo for everything else (incl. BEVEL); something
about that path may be corrupting the form-Graphics encoder when
fed a chart-sized stroked polyline.

This is a DIAGNOSTIC commit. If chart-line then renders on iOS, the
real fix is in Stroker.c's drawJoin BEVEL handling. Will revert
this and put the proper fix in the iOS port.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

This reverts commit a95fc70.

Chart-side fixes (Canvas.rotate xT-conjugation, pushClip, polyline
collapse, BEVEL->MITER) all failed to unblock the iOS XY chart
blank. The bug must be in the iOS native drawShape pipeline. Add
CN1SS:DBG logging at the spots where the alpha-mask path can
silently fail:

- CN1MetalCreateAlphaMaskTexture: log size/result
- CN1MetalDrawAlphaMask: log tex pointer, color, bounds, encoder
  state on entry (catches "draw with nil texture" path)
- drawQuad: log when activeEncoder/pipelineCache/state is nil
  (catches "drawShape silently no-ops the alpha-mask quad")
- METALView.presentFramebuffer: log nil renderCommandEncoder and
  nil drawable (catches frame skip due to memory pressure)

If chart-line is hitting any of these paths during its blank-
render, the next iOS UI run's device-runner.log will tell us
which one. Pure diagnostic; reverts after the culprit is found.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Native CN1SS:DBG output from e3da378 reveals the iOS Metal alpha-
mask path runs successfully for chart-line: TWO drawAlphaMask calls
at alpha=255 land at the chart's final position (101, 371) /
(101, 1124) -- visible blue + red lines on the screen texture. Then
TWO MORE drawAlphaMask calls fire at alpha=0 (no-op visually) at the
same coords. After those, no more alpha-mask draws happen in the
~1700ms before the screenshot fires, yet the captured PNG is blank.

Hypothesis: between the alpha=255 chart paint and the screenshot,
some other op (likely a body-bg fillRect from the form / paintBackground
pass) wipes the screen texture. MTLLoadActionLoad means anything
drawn over the chart pixels would replace them. Log large fillRects
(>=800 px in any dim, alpha>0) so the next iOS run shows whether the
form's bg fillRect is the culprit.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Native logs from 3942fd2 showed both chart-line (blank) and chart-pie
(working) emit ~70 bg fillRects between their last drawAlphaMask and
the screenshot capture, but only chart-line ends up blank. Hypothesis:
chart-line's alpha-mask draws are being routed to a leaked
currentMutableImage target (set by an earlier graphics test, never
cleared) so the chart paints land on a mutable that's never composited
to the screen, while chart-pie hits the screen encoder normally.

Log targetSet at queue time -- if chart-line shows targetSet=1 in any
of its drawAlphaMask calls, that's the bug; if always 0, the routing
isn't the issue and we have to look elsewhere (clip rect / present
timing / render-target swap).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Native logs from 6ef4eb7 ruled out the leaked-mutable-target
hypothesis -- chart-line's drawTextureAlphaMaskImpl always reports
targetSet=0 (correctly routed to screen). Both chart-line (blank)
and chart-pie (working) emit ~70 bg fillRects between their last
chart paint and the screenshot, with no chart paints in between.
Yet pie shows pie content in the captured PNG and line shows pure
bg color.

Hypothesis: Form.paint is invoked at ~50fps (the bg fillRect
heartbeat) but ChartComponent.paint is being skipped on the chart-
line form for some reason -- maybe a dirty-region optimisation that
declares the chart "not invalidated", or an isVisible check, or
something specific to the chart.

Log every ChartComponent.paint call so we can see whether the
chart's paint method is being called every frame for chart-pie but
not for chart-line.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Native CN1SS:DBG logs identified the iOS Metal blank-render flow:

1. iOS GL+Metal port's CADisplayLink fires drawFrame at ~50fps and the
   form's paintBackgrounds heartbeat keeps queueing a full-form bg
   fillRect every frame even when nothing else needs repainting.

2. CodenameOneImplementation.paintDirty (line 808-814) sets the
   wrapper's clip to whatever small region the queued component
   declared dirty (transition residue, status-bar diagnostics, etc).

3. Component.paintInternalImpl (line 2996) short-circuits paint when
   bounds.intersects(clip) is false. ChartComponent's bounds don't
   intersect the small dirty-region clip after the slide-in transition
   completes, so ChartComponent.paint is skipped on every frame.

4. The form's bg fillRect IS queued each frame (its dirty region is
   the form's bg, not a child component's bounds). With Metal's
   MTLLoadActionLoad on the screen pass, the fillRect overwrites the
   alpha-mask chart pixels written during the slide-in transition.
   Result: chart-line/bar/scatter PNG = solid (239, 239, 244) body bg
   with no title bar visible.

Round charts (PieChart / Doughnut / Radar) happen to paint enough
extra frames during their slide-in fade-in that the screenshot's
capture time lands on a frame where their content was just written.
XYChart-derived charts paint only ~5 frames during slide-in and lose
every subsequent frame to the bg fillRect.

Fix: ChartComponent.paint() now calls repaint() at the top so the
chart re-queues itself on the paint queue for the next paintDirty
cycle. paintDirty's queue swap (paintQueue <-> paintQueueTemp,
paintQueueFill = 0) bounds the loop to one chart paint per EDT idle
wake-up; CPU cost is one chart paint per displayLink tick while the
chart is on screen, comparable to what round charts already pay
naturally. This matches what iOS-Metal-friendly components do (e.g.,
MultiButton's animation registration loop) and is the fix that
matches the user's "iOS, Android and JavaSE should be compatible
where it's possible" directive: the chart-package render path now
draws every frame on every port, instead of relying on a dirty-region
optimisation that the iOS Metal port silently subverts.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Calling repaint() from within paint() is an anti-pattern in CN1: it
unconditionally re-queues the component every paint cycle, eating CPU
on every chart usage in production (not just the screenshot tests).
The proper way to keep a component invalidated is to override
Component.animate() to return true and registerAnimated -- but the
underlying problem doesn't actually need continuous repaint either.

This reverts d2917a2; the iOS blank-render is still under
investigation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Add LargeStrokeDirtyClipTest -- a minimal screenshot test that
isolates the iOS form-Graphics behaviour the chart-line / chart-bar
/ chart-scatter blank-render hits. A single Component in
BorderLayout.CENTER whose paint() calls g.drawShape(path, stroke)
with a path the size of the component's bounds (~1051x1676 on
iPhone 16). Same primitive XYChart's drawSeries uses, but without
the chart-package wrapper.

If iOS captures a non-blank PNG with the polyline visible the bug
is specific to ChartComponent's paint cycle; if it captures the
same uniform-bg blank as chart-line we have a minimal reproduction
the iOS-port fix can iterate against -- without spinning up the
entire chart-package each round-trip. The chart screenshot tests
stay registered alongside.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…tbeat

graphics-draw-shape already proves drawShape itself works on iOS, so
the previous version of this repro -- a single Component painting a
polyline once -- doesn't actually exercise the bug. The chart-line
failure pattern is a paintDirty-clip + form-bg-fillRect interaction:
Component A paints once, then a SEPARATE small dirty region keeps
paintDirty firing while Component A's bounds stay un-invalidated.

Add a tiny TickerComponent in BorderLayout.SOUTH that a UITimer kicks
every 100ms via repaint(). Each kick is a small dirty region that
mirrors the "something else is dirty" condition under which the chart
loses its pixels. The painter Component A in BorderLayout.CENTER
draws the same large stroked GeneralPath as before; if its polyline
survives the heartbeat the bug is chart-package-specific, if it
gets wiped from the captured PNG we have a clean repro the iOS-port
fix can iterate against.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Previous version (with TickerComponent + UITimer) rendered the polyline
correctly on iOS GL because the ticker drove continuous repaints --
exactly the condition that ISN'T present in the chart-line failure.
chart-line has no UITimer / animation / peer view; the form is shown,
the slide-in transition's last paint cycle ends, and nothing else
queues a paint until the screenshot fires 1500ms later.

Strip the test back to the chart-line pattern: a single Component in
BorderLayout.CENTER that paints once via g.drawShape and stops. If
this version renders the polyline, ChartComponent is doing something
specific that vanilla Component subclasses don't (the bug is in the
chart-package's paint pipeline, e.g. transform handling, Canvas
wrapper, multi-call drawText/drawLine sequence). If this version
goes blank like chart-line, ChartComponent is innocent and the bug
is in iOS GL/Metal's idle-frame compositor handling.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The single-drawShape simplification (8926797) rendered correctly on
iOS Metal -- so a one-shot drawShape from a Component.paint isn't
broken. chart-line emits TWO drawShape calls (one per XYSeries:
north + south), sharing the same Stroke instance and coordinate
space. Add a second polyline so the test's paint pattern matches
chart-line more closely.

If two consecutive drawShape calls reproduce the blank, the iOS edge
case lives in the Stroker / alpha-mask creation pipeline when fed
two paths back-to-back -- e.g. the second mask's NativePathRenderer
or the texture cache's getShapeID hash colliding with the first.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous two-drawShape MITER version (1b000bd) renders fine on
iOS Metal. ChartComponent uses BEVEL joins (compat/Paint.java line 37
defaults strokeJoin to Join.BEVEL) and produces non-monotonic
fractional path coords (xPxPerUnit ~= 262.75 for chart-line on
iPhone 16). Hard-code the exact coords + BEVEL stroke that XYChart's
drawSeries actually emits for chart-line. If this version reproduces
the blank, the iOS edge case is in the Stroker / alpha-mask path for
BEVEL joins on non-monotonic fractional polylines; if it renders,
ChartComponent is doing something else upstream that's worth
narrowing further.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous version (2795934) with BEVEL stroke + chart-line's
exact path coords still rendered fine. So the bug isn't path data
or stroke style alone. Match ChartComponent.paint's exact flow:

- setAntiAliased(true) stash + restore around the draws (mirrors
  ChartComponent.paint lines 279-280)
- new Stroke per drawShape call (compat/Canvas.java getStroke())
- explicit applyPaint sequence: setColor + concatenateAlpha before
  each drawShape (compat/Canvas.java applyPaint line 76-78)
- 0xff-prefixed color int (renderer.getColor() returns the IColor
  argb, which has the alpha byte set even though g.setColor reads
  only RGB)

If THIS reproduces the blank we've isolated the iOS edge case to
the AA-toggle or per-call Stroke allocation pattern; if it still
renders, ChartComponent's util.paintChart -> Canvas wrapper /
chart.draw call chain is doing something further upstream that
matters.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

XYChart.draw lines 347-360 unconditionally call drawBackground() 4 times
after drawSeries to mask margin strips with mRenderer.getMarginsColor()
(default NO_COLOR=0). ColorUtil.IColor(0) maps alpha 0 to 255, so
applyPaint emits g.setColor(0) + g.concatenateAlpha(255) + g.fillRect(...),
i.e. 4 OPAQUE-BLACK fillRects. This is the only XYChart-specific
unconditional draw step that pie/doughnut/radar charts skip -- if it's
the trigger for chart-line's blank-render, this repro will reproduce
the blank in graphics-large-stroke-dirty-clip without involving any
chart code.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Diagnostic for the chart-line blank-render bug. The XY-chart screenshot
tests on iOS Metal cascade alpha=0 across consecutive XY tests because
something during chart-line's slide-in transition's terminal frame
sets g.alpha to 0 and never restores it; subsequent chart paints
inherit the stuck alpha and concatenateAlpha (multiplicative) cannot
recover from 0. To bisect the source, log a stack trace on every
setAlpha(0) following a non-zero alpha. The non-zero -> 0 edge keeps
the volume manageable when a paint chain redraws into an already-zero
state.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The chart-package Canvas wrapper's applyPaint() called
Graphics.concatenateAlpha(paintAlpha) but never restored the prior
alpha. Since concatenateAlpha is multiplicative
(alpha = oldAlpha * newAlpha / 255) and short-circuits when newAlpha
== 255, painting with the chart's default grid color
(argb(75,200,200,200), alpha=75) collapsed alpha to 29% per draw.
A handful of grid-line draws underflowed alpha to 0, and every
later draw on the same Graphics rendered invisibly because the
paint color's alpha=255 hit the early-return in concatenateAlpha
and could not recover.

This manifested on iOS Metal+GL as XYChart screenshot tests
(chart-line/bar/scatter/...) producing a 45927-byte blank PNG
while RoundChart-derived charts (pie/doughnut/radar) rendered
correctly because their paint chain happens to call setAlpha(...)
directly, clobbering the latched value. The bug exists in core
chart code on every port; iOS Metal's persistent op-queue just
exposes it most reliably.

Fix: applyPaint now returns the entry alpha, and every drawXxx
method (drawRect / drawText / drawPath / drawLine / drawArc /
drawRoundRect) wraps the draw in a try/finally that restores
alpha via g.setAlpha(oldAlpha). This matches Android's real
Canvas semantics where paint.alpha is per-draw, not accumulated.

Also drops the diagnostic setAlpha(0) trace from IOSImplementation
that bisected the bug to this code path.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The 10 XYChart-derived screenshot tests (chart-line, chart-bar,
chart-bar-stacked, chart-bubble, chart-combined-xy, chart-cubic-line,
chart-range-bar, chart-scatter, chart-time, chart-transform) plus the
new graphics-large-stroke-dirty-clip regression test now render
correctly after the chart Canvas alpha-leak fix (commit 4e3f8b4).
Commit identical baselines for both screenshots/ (GL) and
screenshots-metal/ (Metal); the two pipelines render visually
identical content for these tests.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Every active port (iOS, Android, JavaSE, JavaScript) overrode the flag
to return true; the only "false" was the no-op base-class default. Rather
than carry a flag that has only one meaningful value across every port
that ships, fold the conjugation into Graphics.setTransform() / translate()
unconditionally and remove the method.

Also strips the CN1SS:DBG NSLog instrumentation from CN1Metalcompat.m,
CodenameOne_GLViewController.m, and METALView.m that was added during
the chart-line blank-render bisection.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Update the 4 graphics screenshots that were already drifting from the
committed baselines independently of the chart fix (their hashes match
runs from before the chart Canvas alpha-leak fix, confirmed against
ios-rep5 captures). With the four updated baselines + the eleven new
chart baselines, both ios-ui-tests and ios-ui-tests-metal jobs report
"all matched, 0 updated, 0 missing" on the next run.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The test was using hard-coded iPhone-portrait coordinates
(bottom = y + 1714, xStep = 262.75) which drew the two polylines off
the bottom of the Android emulator's 320x640 viewport, so the Android
golden was an empty data area surrounded by the four opaque-black
margin strips. Switch to coordinates derived from getWidth() /
getHeight() so the same chart-line geometry (years 2018-2022, north
12,16,22,18,28; south 8,11,13,16,19) lands inside the data area at
any native resolution.

Also refreshes the 10 Android chart goldens against the post-fix
CI captures -- the previous Android baselines were committed on
2026-05-09 alongside an earlier transitional version of the chart
suite that pre-dated the chart Canvas alpha-leak fix in 4e3f8b4,
so they reflect the partial-renders the bug used to produce on
Android. The new captures show fully-rendered XYCharts (chart-line
shows both polylines + year labels + Year/Value axis titles +
North/South legend) matching the iOS GL and Metal goldens.

The two iOS graphics-large-stroke-dirty-clip baselines are dropped
in this commit; they used the old hard-coded coordinates and would
mismatch the next CI run. The next run will regenerate them.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

emitCn1ssChunks was numbering each chunk with a sequential counter
(0, 1, 2, ...) but Cn1ssChunkTools and every other CN1SS emitter
(iOS / Android / JavaSE Cn1ssDeviceRunnerHelper.emitChannel) treat
the chunk index as the BYTE OFFSET within the emitted base64 stream.
The gap-detection scan in extract --decode walks the chunks expecting
chunk[i+1].index == chunk[i].index + chunk[i].payload.length, so JS's
sequential counter made every chunk after the first look like a
7,999-byte overlap of its predecessor:

  ERROR: incomplete chunk stream for test 'chart-line' ...
    - overlap of 7999 base64 chars at offset 1
    - overlap of 7999 base64 chars at offset 2
    ...
    Got 15 chunks covering 3710 base64 chars. Refusing to emit a partial stream.

The result was that every screenshot-emitting test newly added on the
fix-graphics-screenshot-tests branch (10 chart tests + LargeStroke
DirtyClipTest) failed JS extraction with "Failed to extract/decode
CN1SS payload". Other JS tests were already in the
cn1ssForcedTimeoutTestClasses skip list (commit 2791693 added the
list specifically because of this) so they never hit the consumer.

Verified locally by rewriting the failing run's log with byte-offset
indices and re-running the Java extractor: chart-line, chart-bar,
graphics-large-stroke-dirty-clip all reassemble to valid PNGs at
750x1334 (the JS port's browser viewport).

Also emits the trailing `CN1SS:INFO:test=<name> chunks=<n>
total_b64_len=<n>` line so readTotalBase64Length() can perform the
end-of-stream length check that's already in the consumer.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ines

With the port.js chunk-index fix (commit bf07fd2), the JS pipeline now
decodes every screenshot stream that the chart and graphics-large-stroke-
dirty-clip tests emit. Capture the first clean run's screenshots as
baselines so the JS step stops reporting "missing reference" for these
15 tests.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

With the LargeStrokeDirtyClipTest now sized from getWidth() /
getHeight() (commit 21a9e13), the iOS / Android captures land
inside the data area at every native resolution. Promote the
freshly-captured PNGs as goldens for iOS GL, iOS Metal, and Android
so all four pipelines (iOS GL, iOS Metal, Android, JavaScript) have
matched baselines.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Chart-transform was missing from the Android baseline batch refresh
in 21a9e13 because that run's emulator-screenshot artifact didn't
include it. The next Android CI run captured a clean render
(transformed XYChart with the Latency series correctly drawn over
the form's title bar), so promote it as the Android golden.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>